Malware and exploit campaign detection system and method

ABSTRACT

A malware and exploit campaign detection system and method are provided that cannot be detected by the malware or exploit campaign. The system may provide threat feed data to the vendors that produce in-line network security and end point protection (anti virus) technologies. The system may also be used as a testing platform for 3 rd  party products. Due to the massive footprint of the system&#39;s cloud infrastructure and disparate network connections and geo-location obfuscation techniques, NSS can locate and monitor malware across the globe and provide detailed threat analysis for each specific region, as they often support and host different malware/cybercrime campaigns.

PRIORITY CLAIMS/RELATED APPLICATIONS

This application claims priority under 35 USC 120 and is a continuationin part of U.S. patent application Ser. No. 14/482,696, filed Sep. 10,2014 and titled “MALWARE AND EXPLOIT CAMPAIGN DETECTION SYSTEM ANDMETHOD” that in turn claims priority under 35 USC 120 and the benefitunder 35 USC 119(e) to U.S. Provisional Patent Application Ser. No.61/876,704 filed Sep. 11, 2013 and entitled “Malware And ExploitCampaign Detection System And Method”, the entirety of both of which areincorporated herein by reference.

BACKGROUND

Intrinsically modern drive-by-exploitation and malware campaigns aregrowing in sophistication related to obfuscation, deployment, andexecution in an effort to avoid detection and analysis by securityresearchers, and modern security systems and software. Anti-virus (AV)systems, such as endpoint protection platforms (EPPs), as well as breachdetection services (BDS) employ virtual “sandboxes” or “honey nets” thatoperate in a cloud (virtual) network construct. These sandboxes attemptto identify malware and virus programs by incubating the suspectsoftware until such time as the malware executes and its activities canbe monitored and analyzed.

These systems often fail to identify previously unknown malware due tothe evolution within malware development that allows the malware torecognize when it is sitting in such a system/trap. Modern malware canbe considered to be “cognitive” and completely aware that it iscurrently being incubated within a trap (monitored system), and willcontinue to hibernate and therefore will not present itself as malicioussoftware.

Thus the sandbox system will fail to identify the suspect file as beingmalicious, and therefore will allow all similar programs to bypassfuture testing. Another shortcoming is that they rely on monitoringtraffic that is already affecting the victim machine or network, andbecause these sandbox systems are incapable of operating in-line due toperformance limitations, they are unable to actually prevent the attack.The best the conventional systems can do is to inform when a breach hasalready occurred and thus can never be predictive.

BRIEF SUMMARY

The system and method for malware and exploit campaign detection (thatmay be known as “BaitNET”) is different than known systems since thesystem has technology that prevents detection of the system by themalware/exploit. Unlike other technologies, BaitNET cannot be detectedby modern malware/exploits and thus the operations/actions of themalware/exploits can be collected and analyzed without restriction. Thecollected malware/exploit is replayed/tested against various operatingsystem and application configurations within BaitNET's private cloudinfrastructure to determine what other system footprints are susceptibleto the malware campaign. BaitNET is able to successfully incubate,track, and inventory the malware/exploit. Due to the transparency ofBaitNET to the malware/exploit, BaitNET is able to perform live analysisthat that can track threat actors, identify where they are trulylocated, and what other similar malware/exploit campaigns they have beenlaunching and against whom. All of this is done while BaitNET producesthreat forecasts that indicate viable and potential targets of thethreat actors. BaitNET can also be used to measure and test theeffectiveness of commercially available EPPs, AVs, in-line networksecurity appliances, and BDS systems. This is done by injectingmalware/exploits into BaitNET's construct, where these commercialproducts have already been installed, and then monitoring the deltabetween what BaitNET knows was injected, and detected itself, and whatthe commercial product claims to have detected. E.g., BaitNET is anadvancement in technology so far beyond modern AV, EPP, and BDS that itis used to test the efficacy of these commercial products.

In one implementation, BaitNET is the conglomerate of a number ofsoftware applications, processes, and innovations as outlined hereinwhich afford BaitNET the ability to shim into the operating system andthe virtual machine architecture (both guest and host) enabling BaitNETto obfuscate the fact that the machine itself is a virtual/unmannedcomputer. The system utilizes a multitude of virtual private networks(VPNs) allowing a near-unlimited number of unique Internet IP addressesfrom all across the world to be used. These disparate IP addressesafford two primary advantages to BaitNET. One, in order to forcere-infection, as many malware system will not “drop” (deploy) malware tothe same IP address more than once, it is necessary to have BaitNETobfuscate its Internet presence. Two, many malware campaigns limit theirtargets by geo-location, which is often tracked via IP Address. E.g.,Malware-infected servers often limit themselves to only infecting one(1) computer from any given masked IP address, and may limit the countryof origin of the IP addresses that they will infect. BaitNET utilizesVPNs throughout the world to mimic dispersed geo-location and map outmalware campaigns in different regions. Other techniques, while notproprietary to BaitNET, may also be used to emulate potential targetqualification data points such as varying the language pack and keyboardlanguage configuration on the host operating system.

After finding new malware, done by crawling URLs provided throughvarious channels, BaitNET records the attack vector, payload, criticalinformation on exploitation, and other relevant metadata and then“replays” this attack against thousands of other hosts on the BaitNETnetwork. “Replay” is achieved through the use of BaitNET's proxyservices, as outlined later in this document, and may be done against asingular image when testing the efficacy of a 3^(rd) party securitysystem or against limitless iterations of operating systems, applicationconfigurations, and versions of software tools when mapping theeffectiveness of the exploit/malware. Each of the hosts used during thereplay has a different combination of web browser, suite of installedapplications, various program and operating system patch levels,installed language packages, etc. The representation of systems ofnearly all possible combinations, Windows and OS X, from 2005 to presentday. BaitNET is also capable of emulating mobile device operatingsystems, and uses the same technology to detect and inventorymalware/exploits. All of this allows researchers to understand the truetarget landscape/scope for the malware/exploit, and the malware/exploitcan be tested against anti virus (AV) and in-line security systems suchas intrusion prevention systems (IPS), next generation firewalls (NGFs),and breach detection systems (BDS.)

The BaitNET Framework is a distributed automation framework for testingURLs in real time to detect drive-by-exploitation attacks and malwaredropped by said attacks, and gather data from said attacks to aid intheir further analysis and prevention. URLs are tested using variousoperating system and application configurations within BaitNET's cloudinfrastructure to determine if they are maliciously serving exploits. Ifa URL is found to be malicious, BaitNET is able to successfullyincubate, track, and inventory the attack.

Due to the transparency of BaitNET to the exploit and any malware itdrops, BaitNET is able to perform live analysis that that can trackthreat actors and fully enumerate their capabilities (i.e. which exploitkits they are using, which specific exploits are employed, whichapplications are being targeted, and full details of the exploitsthemselves). BaitNET therefore produces accurate predictions of whichapplications are being targeted in current campaigns by threat actors,providing predictive threat analysis AHEAD of any breach.

BaitNET can also be used to measure and test the effectiveness ofcommercially available security products, both network and host-based.This is done by replaying captured exploits using the same BaitNETinfrastructure in which commercial security products have beeninstalled. BaitNET is capable of monitoring the delta between whatBaitNET detected during the initial capture process, and what thecommercial product claims to have detected.

BaitNET has the concept of a Controller that acts as both a unit of workventilator, or producer, and a lightweight in-memory message pump.Worker nodes, referred to as Victims, register themselves with theController to process units of work. The unit of work in BaitNET is aURL. Subscriber nodes, referred to as Notification Sinks, registerthemselves with the Controller to receive notifications about a URL'sresult as a Victim is processing it. The Controller, through a series ofsteps, distributes URLs to registered Victims to be processed, receivesthe results, and publishes them to registered Notification Sinks.BaitNET's cloud infrastructure is composed of a one or more Controllersand thousands of Victims preferably deployed in a virtualizedenvironment. The exact number of Victims is based on the scope and scaleof the testing and research being performed. Victims are machines with aunique operating system and application configuration that areresponsible for testing URLs assigned to them by a Controller.

BaitNET is capable of running on “bare metal” machines however due toits nature in testing potentially malicious URLs, a virtualizedenvironment is preferred such as that when a Victim is comprised, it canbe automatically reset to a clean state. BaitNET is not limited to aspecific hypervisor thanks to its modular design. Its default virtualadapter is for VMware ESXi but it was originally designed to work withMicrosoft Hyper-V. Additions can be made in the form of additionaladapters, which would allow it to run on any hypervisor, thus supportingmultiple hypervisor communication channels, possibly within the samedeployment if needed.

BaitNET provides a malware and exploit campaign detection system andmethod that cannot be detected by the malware or exploit campaign. Thesystem may provide threat feed data to the vendors that produce in-linenetwork security and endpoint protection technologies. The system mayalso be used as a testing platform for 3rd party products. Due to themassive footprint of the system's cloud infrastructure and disparatenetwork connections and geolocation obfuscation techniques, NSS canlocate and monitor malware across the globe and provide detailed threatanalysis for each specific region, as they often support and hostdifferent malware/cybercrime campaigns.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the high-level architecture of the major components of asystem for malware and exploit campaign detection that may be known asBaitNET.

FIGS. 2A-2D illustrates the process control and internal operations ofthe BaitNET Controller Process and its interoperability with theCapture, Replay, and Proxy processes.

FIGS. 3-6 are examples of the user interface of the BaitNET system ofFIG. 1.

DETAILED DESCRIPTION OF ONE OR MORE EMBODIMENTS AND IMPLEMENTATIONS OFTHE SYSTEM AND METHOD

The system and method for malware and exploit campaign detection (knownas BaitNET) is designed to seek out, detect, itemize, and retest activeURLs serving drive-by exploits. BaitNET is a multi-leveled applicationoperating within the kernel and user layers of the operating system thatmake it unique when compared to similar technologies utilized to detectand prevent malware.

Note that the distinction is important—malware is the payload that isdelivered by an exploit. There are literally hundreds of thousands ofmalware samples in the wild, and it is a trivial matter to obfuscatethese or morph them into something new. In contrast, there are only afew hundred active exploits in the wild at any given point in time—theexploit is the mechanism whereby the threat actor compromises the systemin order to deliver and execute the malware. By identifying and blockingexploits, BaitNET moves further up the kill chain from traditionalmalware protection products and provides much more effective andfar-reaching predictive capabilities.

BaitNET's core technology could be used to prevent exploitation as wellas detect, but that is not its primary function. By operating out ofband, BaitNET is freed from the usual restrictions of real-time orin-line protection technologies, allowing it to be much more accurateand thorough in its detection capabilities. BaitNET supports varioustypes of operating systems as a threat forecast system. BaitNET'svirtual machines (VMs) can simulate servers, workstations, even mobilecomputing devices such as smartphones and tablets.

As shown in FIG. 1, a system 100 may utilize three arrays of servers andnetworking hardware known as “stacks.” Each stack is any number ofphysical servers that host virtual machines (“guests”.) The exact numberof servers and guests is based on the scope and scale of the testing andresearch being performed. Typically, within “Live Testing” this will bemany tens of thousands of guests. FIG. 1 illustrates theinteroperation/communication of the various stacks of servers and guestswith the infrastructure support servers, as well as which componentshave Internet 102 connectivity.

Specifically, the system may be implemented using the computingresources shown in FIG. 1 including the stacks. As shown in FIG. 1, thesystem may be implemented with a capture stack 104, a replay stack 106,a proxy stack 108. The system may also have a master hypervisorcontroller 110 that controls each of the stacks as well as one or moredata stores 112 (for storage of data and the like). As shown in FIG. 1,the capture stack 104 and the proxy stack 108 have access to a computernetwork 102, such as the Internet. The capture stack 104 implements thecapture process 204 described below, the replay stack 106 implements thereplay process 206 described below and the proxy stack 108 implementsthe proxy process 208 described below. Each of the stacks may beimplemented using one or more computing resources, such as one or morecloud computing resources or one or more server computer resources. Eachof the one or more computing resources may have a processor and memoryand a plurality of lines of computer code that may be stored in thememory and executed by the processor to implement the capture, replayand proxy processes described below. Each of the stacks also may beimplemented as one or more virtual machines that are controlled by thehypervisor controller 110.

FIGS. 2A-2D illustrates the process control and internal operations ofthe BaitNET Controller Process (implemented by the master hypervisorcontroller 110) and its interoperability with the Capture, Replay, andProxy processes. Each of the processes shown in FIGS. 2A-2D may beimplemented as a module/unit/device that is part of the respectivestacks shown in FIG. 1 and each process may be implemented in software(a plurality of lines of instructions/computer code executed using aprocessor) or as a hardware device that is part of the respective stackshown in FIG. 1. A controller process 210 and part of a replay process206 are shown in FIG. 2A with the replay process 206 also being shown inFIGS. 2B and 2C as shown by the reference designators (A and E) thatshow how FIGS. 2A, 2B and 2C connect to each other to show the replayprocess 206. FIGS. 2B and 2C also show the details of the captureprocess 204 as shown by the reference designator D that shows how FIGS.2B and 2C connect to each other to show the capture process 204. FIGS.2B and 2C also show a ZeroDay process 220 as shown by the referencedesignator B that shows how FIGS. 2B and 2C connect to each other toshow the ZeroDay process 220. FIGS. 2B and 2C also show the proxyprocess 208 as shown by the reference designator C that shows how FIGS.2B and 2C connect to each other to show the proxy process 208. Finally,FIG. 2D shows the details of an Obfuscation Engine 222 with references Fand G showing the interchange between the capture process 204 and theObfuscation Engine 222. Also illustrated are the interchanges with theObfuscation Engine, Exploit Feed, and ZeroDAY modules. FIGS. 2A-2C showan enumeration process as shown by the reference designators (I and H)that show how FIGS. 2A, 2B and 2C connect to each other to show theenumeration process.

The system and method for malware and exploit campaign detection shownin FIGS. 1-2D and described above may be typically operated by anentity, such as NSS Labs (“NSS”), as a cloud-based system that is usedby the entity to perform the malware and exploit campaign detection asshown in FIG. 1. However, the system and method for malware and exploitcampaign detection may also be installed on a premises of a customer andperform the same malware and exploit campaign detection. Using sourcesfrom around the globe, BaitNET's process begins with the correlation andnormalization of multiple threat feeds for information regardingpotentially malicious websites. This normalized data is presented toBaitNET's Capture Process 204 and is queued as targets for each of theconfigured operating system variations that are assigned to series oftesting.

BaitNET, using the Capture Process 204, issues the URL to each of thethousands of Victims, utilizing thousands of variations inconfigurations, and each Victim in turn visits the URL using disparateVPN tunnels, upstream HTTP proxies, and even physical data centers,located around the world, to obfuscate their true geographical locationas well as to explore the geolocation filtering that may be employed bythe malicious URL.

If successful, a visit to the URL will result in exploitation of theVictim (the “exploit”) sometimes (but not always) followed by a “drop”of malicious code (the “malware”) to the target workstation. BaitNETmonitors the progress of the exploit and records the network traffic,creates a copy of the malicious code, and catalogs all changes to theoperating system made by the malicious code during the capture process204. Any malware dropped on the Victim is also captured, as are theeffects of executing that malware on the Victim.

Note that one of the unique features of BaitNET is that, unliketraditional anti-malware security solutions, even if no malware isdropped, the exploit is still detected and captured. Additionally, theCapture Process 204 may record any and all outbound communications fromthe now infected/compromised Victim. This outbound traffic will includeany command and control (C&C) communications, often identifying the truethreat actor, as well as any data being exfiltrated from the nowinfected Victim.

Validation of the recorded data occurs by analyzing the events that weregenerated on the Victim. Note that this process occurs in seconds, notminutes, hours, or even days. This is possible because BaitNET analyzesthe contextual relationship between the events that were generated toconfirm infection. Furthermore, as a threat forecast system, the longerBaitNET is online and the more data it gathers, the more efficient itsanalysis becomes.

When infection is confirmed, BaitNET provides information such as theURL where the attack originated, the type of URI/attack used, the IPaddress of the server that hosted the malicious URL, and the country oforigin of the IP address (aka “geolocation.”). For example, FIG. 6 showsdetailed information on the URI and network behavior of the maliciouswebsite when accessed by the guest systems inside of BaitNET Furtherdetail is presented on the operable target platform(s) that weresuccessfully infected with the malicious content. The hashes (MD5) ofthe malicious executables (files) along with the exact size of each fileare also made available. The network packet capture (PCAP) data as wellas the decoded HTTP traffic that is relevant to understanding the attackvector is also available. Provided are the full URI, protocol of theattack (i.e. HTTP/1.1) the specific web browser used (i.e. InternetExplorer 11), the actual URL of the drop (i.e. .DE, Germany, domain), aswell as information about the server such as the web server operatingplatform (i.e. Apache 2.0.59 running on a UNIX operating system withOpen SSL). This information can be used by end-users to write firewallrules as well as other rules within in-line systems such as IPS, IDS,WAF, and NGFW. The information can also be used to update endpointproducts such as anti-virus to now identify the hash values of the nowknown malicious content and block it from either being downloaded orexecuted. The exact vector of the attack being provided; which includeshosting, transmission, and target configuration are vital pieces ofinformation that are uniquely provided by BaitNET.

The Victim that was successfully infected is now reset to its virginstate, thus preparing it to be reused for the next URL in the queue. Allthe data collected is stored in a data store used for logging andintelligence. BaitNET is modular enough to support any number ofdifferent storage technologies, including everything from traditionalrelational databases, NoSQL databases, and even graph-based databases.

The infected URL is now queued up for the Replay Process 206 using datafrom the data store. During the Replay Process 206, Victims matching theconfiguration of the Victim that successfully was infected during theCapture Process 204 are prepared for testing of the malicious code. Toprepare the Victims, all recent versions of products being tested(in-line security devices to endpoint protection products) areautomatically configured. Copies of the workstation used during theCapture Process 204 are configured with the latest versions of any andall endpoint protection products being tested. In-line security productssuch as intrusion prevention systems and next generation firewalls standin wait on the network between the Victims and the Replay Servers. TheVictims visit an internal (LAN-based) URL that has been created byBaitNET as a perfect copy of the malicious URL that was validated duringthe Capture Process. As each copy of the Victim is presented theinternal URL, BaitNET once again monitors the Victim capturing allmetadata related to the malicious code. If the code is successful inreaching the Victim and then executing properly, the endpoint protectionproduct being tested has failed to identify and/or stop the maliciouscode. If, during the visit to the internal URL, the drop is prevented,thus malicious code is prevented from ever reaching the Victim, then thein-line security product was successful in identifying the exploit andworked as designed.

During the Replay Process 206, the effectiveness of the malicious codeis tested in a live environment. For example, all major makes andversions of web browsers are tested to determine which are susceptibleto the exploitation during a drive-by-exploitation attack (i.e. anattack that executes within the browser and does not require theend-user to manually execute the malicious code). Different versions ofapplication systems, language packs (localization data), base operatingsystem revision, and even different architectures can be checked againstthe copy of the malicious URL and the malicious code itself.

During the Replay Process 206, an emulated HTTP proxy is generated andutilized. This HTTP proxy facilitates the ability of BaitNET to performcontinual testing against the malicious URL that was collected duringthe Capture Process without the need of the original/actual maliciousURL. This is important due to the short lifespan of most malwarecampaigns, security features within the malware campaign to identify andprevent drops of malicious code to systems on the same network, and toobfuscate/protect the research and investigation into the malwarecampaign. The HTTP proxy uses the original source code of the maliciouswebsite as recorded by the Capture Process 204. The HTTP proxy emulatesthe remote server, source code of the website, and will serve (hand-out)the malware in the same way that the original website did. Note that anHTTP proxy, as a technology, is not in itself unique. The use of an HTTPproxy that is generated dynamically to emulate recorded network trafficin order to test the effectiveness of security products withoutdepending on a live malware campaign and mimicking real live networktraffic, as opposed to a dummy network traffic generated by networkpenetration tools, is the unique advantage provided by BaitNET.

The Capture 204 and Replay 206 Processes can be used to continue tocheck localization configurations and geolocation exit points on theInternet to determine the full scope of the attack vector, provideintelligence on the threat actor(s), and harvest as much viable metadataas possible. These processes are key in enumerating the variousconfigurations of operating system, browser, applications, securityproducts, etc. that the malware can use to successfully execute itself.The collation of this intelligence allows modeling to be performed, aswell as direct risk assessments, so that consumers understand if theirsystems, networks, and tools are at risk—and what to do, if anything, toprotect them against active exploit/malware campaigns.

All data are retained in the data stores and can be reused by BaitNET atany time. New Victim configurations can be presented to the capturedmalicious URL for future testing. All tested products can be retested toconfirm that patches/updates supplied by the vendor are working asdesigned, to outline exactly which systems provided by 3rd parties aresusceptible to the attack (“Gold Images”), and to validate attack datacaptured during the Capture Process.

The system and method shown in FIGS. 1-2D may define a messagingprotocol, dubbed as Horus, that is an application level protocol andconsists of a set of rules for messages that are exchanged between aController 110, a set of Victims, and a set of Notification Sinks. Eachmessage has a special sematic meaning and is meant to provoke a certainbehavior. Horus consists of two sub-protocols: Horus/Victim whichdefines how a Controller communicates with Victims andHorus/Notification which defines how a Controller and Victimscommunicate with Notification Sinks.

Horus/Victim is a synchronous and stateful request-reply protocol, morecommonly referred to as an RPC protocol, for two endpoints, a client anda service, to communicate with one another. The client sends a request.The service reads the request and sends a response. The client reads theresponse. Both the client and the service are responsible formaintaining state for the duration of a session. In BaitNET, the clientis a Controller and the services are the Victims.

Horus/Notification is an asynchronous and stateless publisher-subscriberprotocol for one endpoint, a publisher, to communicate with a set ofendpoints that is of an undefined size, the subscribers. Subscribersregister with the publisher their interest in receiving messages. Thepublisher broadcasts messages to the subscribers. Subscribers receiveall messages broadcast by the publisher that they are interested in. Thepublisher expects no response from the subscribers. InHorus/Notification, the subscribers are the Notification Sinks. Both aController and Victims in different parts of Horus' topology fulfill therole of the publisher.

A Controller is a producer, or ventilator, that MUST produce URLs to bedistributed to interested Victims. A Controller is also a message pumpthat MUST collect results that are produced by Victims and MUST publishthem to interested Notification Sinks. We refrain from using the term“broker” to describe a Controller in its role as a message pump eventhough its purpose seems analogous to one. Traditional middlewarebrokers are too complex, too stateful, complicate an application'sdeployment model, and are usually meant to serve as a shared entitybetween many different disparate systems. The Controller as a messagepump thus acts more like an intermediary to push data downstream tointerested Notification Sinks, like a switch, to avoid a mesh topologybetween them and Victims.

A Victim is a consumer, or worker, that MUST consume URLs and processthem. A Victim MUST either publish its results to a Controller or itMUST maintain its results as state until a Controller explicitly pollsit for them, depending on the topology deployed. In either case, theController MUST always forward the results downstream to interestedNotification Sinks. A Notification Sink is a collector, or subscriber,that SHOULD collect results produced by Victims. A Notification SinkSHOULD register with a Controller its interest in receiving resultsproduced by Victims. In Horus, Notification Sink interest is referred toas a Subscription.

Victims are discovered using a method we refer to as hybrid discovery.Hybrid discovery is a mix between traditional static and dynamicdiscovery methods.

Static discovery refers to Victims being known beforehand. This isanalogous to a having a configuration data store of some sort, such as aconfiguration file, a configuration database, or even a hard codedin-memory collection, which contains relevant information aboutavailable Victims within a network. This form of discovery is relativelyeasy to implement but obviously requires Victims to be deployed manuallybeforehand.

Dynamic discovery refers to Victims dynamically being deployed andproviding a notification to a beacon that they are available. This formof discovery is incredibly difficult to implement but offers the mostflexibility for certain use cases. In BaitNET however, Victims areusually deployed in a virtualized environment so that they can be resetto a clean state after they process a URL. BaitNET recognizes theimportance of running in a virtualized environment for that very reasonand thus has first class support for it. In a virtualized environment,virtualized Victims can be deployed, and in some advanced uses caseseven provisioned, dynamically. Because complete control over theenvironment is possible, Victims do not need to notify a beacon on whenthey are available. Thus, we refer to this mode of discovery as hybriddiscovery: its static in the sense that the virtualized environment isknown before hand and dynamic in the sense that Victims can be deployedor provisioned dynamically in that environment.

Victims are implemented as finite state machines, with each staterepresenting a step in its progress in processing a URL. This allows theController, with high level of accuracy and without the dependency onthird party middleware products, to track the Victims and to distributeURLs to them as they become available. The different states are:

Available—Indicates the Victim is available and ready to process a URL

Booting—Indicates the Victim has received a URL from a Controller and isin the process of booting

Acquired—Indicates the Victim has successfully launched a browser andnavigated to the URL

Completed—Indicates the Victim has successfully completed monitoring thesystem and collected relevant data

Error—Indicates the Victim has encountered an error and might need to bereset

FIG. 3 is an output from the system, which illustrates validatedexploits that have been discovered by the BaitNET system. The capturedate, e.g. the date and time the malware or exploit was downloaded, isshown along with the corresponding source URL (Universal Record Locator)which shows the full path to the file on the infected/malicious website,the exact operating system that was used on the guest (virtual)workstation that the malware/exploit executed upon, and the exactapplication that the malware/exploit targeted (needed to be successful.)In this example, the first exploit in the list uses Java version 6update 27 on Microsoft Windows 7 and was downloaded from a URL which wasredirected (linked) on a google.com website. A user of the system canclick any of these fields to drill-down into more detailed information.E.g., The “Source” section provides IP addresses, packet capture data,geo-location information, etc.

FIG. 4 is output from the system which illustrates detailed informationon the “drop” or malicious file that was downloaded and has beenvalidated to be malware/exploit code. Again the pertinent date and timeis displayed, a unique filename is presented which was generated by thesystem when the malware/exploit was captured. This file contains themalicious content and can been downloaded in its archived (safe) versionfor inspection and reverse engineering. The hash value (MD5) of thearchived file is presented so that the end-user can validate the filefrom the repository has not been altered. The system will indicate, aspresented in this example, that the malware/exploit has been validated.Validation occurs when the BaitNET system utilizes the Proxy and ReplayProcesses to confirm infection and execution of the capturedmalware/exploit. The center section of the page reflects the URI wherethe file was collected from (This matches the data on FIG. 3) the typeof URI/attack used, the IP address of the server that hosted themalicious file, and the country of origin of the IP address (aka“geo-location.”) Further detail is presented on the operable targetplatform(s) that were successfully infected with the malicious content.

FIG. 5 is more detailed information from the system with regard tomalicious content (malware/exploit code) that was captured. Here theend-user can find the hash (MD5) of the malicious executables (files)along with the exact size of each file. This information can be used toupdate in-line security systems such as an IPS, NGFW, or even endpointproducts such as anti virus to now identify the hash values of the nowknown malicious content and block it from either being downloaded(in-line devices) or executed (end point products.)

For Threat Forecasting, the Enumeration Process/scout algorithm can beused to continue to check localization configurations and geolocationexit points on the Internet to determine the full scope of the attackvector, provide intelligence on the threat actor(s), and harvest as muchviable metadata as possible. This process is key in enumerating thevarious configurations of operating system, browser, applications, etc.that the malware can use to successfully execute itself. The collationof this intelligence allows modeling to be performed, as well as directrisk assessments, so that consumers understand if their systems,networks, and tools are at risk—and what to do, if anything, to protectthem against active malware/exploit campaigns.

In one implementation, the entire BaitNET suite of processes may takeplace in parallel, currently utilizing four parallel threads that areresponsible for managing each of the aforementioned processes (Capture,Replay, and Proxy) along with their sub-processes such as theObfuscation Engine shown in FIG. 2D and modules covered within thisdocument such as ZeroDAY and are collectively controlled from theControl Process. Additionally monitoring of the virtual machines (VMs)and the setup and tear down (establishment and reverting) of the VMsalong with their guest operating system and application configurationstake place from within the Controller Process.

Full control of the VM architecture is done through BaitNET's ControllerProcess (implemented by the Master Hypervisor Controller in FIG. 1),which is modified to operate natively. This control is automated andfunctions as a separate thread during the Control Process and works inparallel with the Capture, Replay, and Proxy processes. BaitNET canprocure, configure, and operate VMs on demand, autonomously, and scaleresources during testing.

Additional cloaking technologies that prevent detection of BaitNET arecovered herein within the model overviews.

As outlined herein, BaitNET is a system of custom developedapplications, application program interfaces (APIs), and kernel-levelmodification, such as the AT Module of the system, the ObfuscationModule of the system, the ZeroDAY module of the system and the captureprocess, for example which are applications. The applications are forboth the hypervisor host and the guest functionality as well as theoperating systems. BaitNET currently supports all versions of MicrosoftWindows operating system, all Intel-based versions of OS X, iOS, andAndroid. One key feature for BaitNET is its ability to render the “VMDetection System” (e.g. ability to discern a virtual machine from aphysical/real machine by malware) found in modern malware/exploitsuseless. This thwarts the ability of malware to detect a VM, which wouldnormally prevent it from deploying its payload as VMs are often used inanti virus systems to incubate suspected executable files.

BaitNET's functions are expanded and complimented through the use ofmodular components (Modules) described below in more detail, each ofwhich provides functionality used in threat forecasting and theevaluation of 3^(rd) party security product effectiveness as shown inFIG. 2.

Capture Process 204

BaitNET's Capture Process 204 may be implemented using a scout process(that may be implemented as an algorithm when this process isimplemented in software.) The scout process may also be referred to asan enumeration process. Like classical battle strategies in which asmall scout party is detached from the main fighting force and sent outto gather intelligence about the enemy fighting force and theintelligence gathered helps in formulating a strategy for winning thebattle, the scout process is designed to seek out, by testing, as manyURLs as possible to determine if they are malicious. The intelligencegathered is thus which URLs are worth spending precious computingresources against to determine the capabilities of the threat actors.

URLs are gathered from a variety of different sources from around theglobe. The system correlates and normalizes URLs from multiple threatfeeds for information regarding potentially malicious websites. TheseURLs are then queued up for testing.

The Scout process may define what may be referred to as Tiers. Tiers aresets of victims that are configured to test URLs using an operatingsystem, browser, and application(s) combinations. Each victim may be avirtual machine having an operating system, browser, and one or moreapplication(s) configuration with different strategies against which anexploit may be tested to determine if the URL is malicious with respectto each particular configuration of each victim. The Scout process maydefine three Tiers, each representing a different strategy.

Tier 1 defines a set of victims that have a combination of operatingsystems, browsers, and applications that are highly targeted by exploitkits. More than one application can be installed on the victim but onlyone operating system and one browser can be installed. The configuredcombination is reinforced through ongoing research of the threatlandscape and will change when the thread landscape changes.

The purpose of Tier 1 is to test as many URLs as quickly as possible anddetermine if they are malicious. Identifying the full capabilities ofthe threat actor on Tier 1 is not important. Malicious URLs are normallylive, that is to say they are either infected or publicly accessible,for a short amount of time. And they usually represent a smallpercentage of the overall number of URLs that will be tested. It is thusimperative that they are tested as quickly as possible. Multipleapplications are usually installed on Tier 1 Victims, though that is notabsolutely necessary, to maximize the possibility of adrive-by-exploitation attack taking place. The URL distributionalgorithm on Tier 1 is a simple load balancing or round-robin algorithm.Essentially the URLs that are queued up for testing are distributed toeach available Tier 1 Victim, in parallel. As each Tier 1 Victimcompletes testing one URL (by accessing the URL to determine if the URLis malicious), it is assigned the next URL in the queue until the queueis exhausted. Once the queue is exhausted, the Tier 1 Victims remainidle until more URLs are queued up. The more Tier 1 Victims that areavailable the more URLs that can be tested. When a URL is found to bemalicious by a Tier 1 Victim, it is queued up for further testing onTier 2.

Similar to Tier 1, Tier 2 defines a set of victims that have acombination of operating systems, browsers, and applications that arealso highly targeted by exploit kits. Unlike Tier 1 however, only oneapplication can be installed on the Victim. The configured combinationis reinforced through ongoing research of the threat landscape and willchange when the thread landscape changes. The Tier 2 combination ofoperating systems, browsers, and applications is a superset of the Tier1 combination.

Drive-by-exploitation exploit kits usually fingerprint the Victim when amalicious URL is tested. Based on the configuration of the Victim, adifferent exploit might be served. Consider, for example, a Tier 1Victim that has both Microsoft Silverlight and Adobe Flash Playerinstalled. When such a Victim tests a malicious URL, the exploit kitmight fingerprint the Victim and determined that both MicrosoftSilverlight and Adobe Flash Player are installed. It's entirely possiblethat the exploit kit supports both Microsoft Silverlight and Adobe FlashPlayer. However, randomly at runtime, the malicious URL might decidethat it will only serve an exploit targeting one of the applications.

This is where the benefit of Tier 2 comes in, and the primarilydifference between it and Tier 1. On Tier 1, the URL was identified asmalicious but there is no strong indication on the full extent of thecapabilities of the threat actor. When the URL is queued up on Tier 2,two Victims, one with Microsoft Silverlight only and one Adobe FlashPlayer only, will be instructed to test the URL. Now, if the exploit kitsupports both applications, testing the URL again on Tier 2 will derivea possible addition of two more exploits, bringing the total number ofexploits potentially being served by a single URL to three. The totalnumber of exploits is three because the operating system and the browserare also considered as attack vectors in addition to the two installedapplications. This is also why it is imperative that, similar to Tier 1,the URL must be live when it is tested on Tier 2.

Of course, it is not only applications that are tested on Tier 2 butalso different operating systems and browsers. The below matrix is anexample of the possible different combinations a URL can be testedagainst if it is found to be malicious on Tier 1 and queued up on Tier2:

Tier 1 Tier 2 Operating Operating System Browser Applications SystemBrowser Application Windows 7 Internet Adobe Flash Windows XP InternetN/A Explorer 9 Player, Explorer 8 Microsoft Windows 7 Internet N/ASilverlight Explorer 9 Windows 7 Internet Adobe Flash Explorer 9 PlayerWindows 7 Internet Microsoft Explorer 9 Silverlight Windows 7 InternetN/A Explorer 10 Windows 7 Internet Adobe Flash Explorer 10 PlayerWindows 7 Internet Microsoft Explorer 10 Silverlight Windows 7 InternetN/A Explorer 11 Windows 7 Internet Adobe Flash Explorer 11 PlayerWindows 7 Internet Microsoft Explorer 11 Silverlight Windows 8 InternetN/A Explorer 10 Windows 8 Internet Adobe Flash Explorer 10 PlayerWindows 8 Internet Microsoft Explorer 10 Silverlight Windows 8.1Internet N/A Explorer 11 Windows 8.1 Internet Adobe Flash Explorer 11Player Windows 8.1 Internet Microsoft Explorer 11 Silverlight Windows 10Microsoft N/A Edge Windows 10 Internet N/A Explorer 11 Windows 10Internet Adobe Flash Explorer 11 Player Windows 10 Internet MicrosoftExplorer 11 Silverlight

This matrix is just a small example of the many combinations that can betested and does not even include different mainstream browsers likeGoogle Chrome and Mozilla Firefox. The large number of possiblecombinations that need to be tested is the primary reason for havingdifferent Tiers in the scout process.

Ongoing research has suggested for quite some time now that only about10% of URLs are malicious at any given point in time. BaitNET's designtakes into consideration that computing resources are precious and thusdoes not attempt to test a URL using every possible combination simplyto determine if it is malicious. Instead, on Tier 1 it simply identifiesthe 10% that are relevant and throws away the remaining 90%. It is onlythose 10% that are tested against the remaining combinations. This meansnot only massive savings in time but also in the costs associated inrunning BaitNET. It is also a precursor for Tier 3.

Tier 3 defines a set of Victims that have the same combination ofoperating systems and browsers as Tier 2 but with different versions ofthe applications. For example, if Tier 2 is configured to test MicrosoftSilverlight 1, and there are ten versions of Microsoft Silverlightreleased, Tier 3 will have Victims with the remaining MicrosoftSilverlight 2 through Microsoft Silverlight 10.

Normally, a single exploit will take advantage of a vulnerability thatimpacts multiple different versions of an application. It's important tonote however that for Tier 3, the Victim does not need to test the URLwhile it is live. Once a session of the attack has been recorded oneither Tier 1 or Tier 2, it can be tested against multiple differentversion of the same application. Since the attack has been recorded andit impacts multiple versions, Tier 3 does not need as much computingresources as Tiers 1 and 2 since there is no longer a requirement totest the URL as quickly as possible.

The enormous size of BaitNET's cloud infrastructure requires that itsdesign take into consideration the fact that computing resources areboth precious and costly. With the massive number of combinations that asingle URL needs to be tested against across all three Tiers, it issimply not realistic to require a single Victim per combination. Even ifthat was the case, as the number of URLs that need to be tested grows, asingle Victim will not be able to test them all fast enough. Recall,that on Tier and Tier 2, a URL must be tested as quickly as possiblewhile it is live. For this reason, Victims can be provisioneddynamically, based on the target number of URLs that need to be testedin a time period. Similarly, browsers and applications can be installeddynamically on the victims such that there doesn't need to be onededicated Victim for each combination.

The success of BaitNET's Scout process is evident by the large number ofURLs that can be processed in a 24-hour period using relatively littlecomputing resources. With a mere 400 Victims, BaitNET can successfullyprocess in excess of 250,000 URLs in a 24-hour period which isabsolutely phenomenal in comparison to other threat forecasting systems.

ZeroDAY Module/Process 220

This module 220 is a state of the art plugin for the BaitNET systemallowing it to detect any type of exploitation attack, and was developedto identify 0day attacks, e.g., exploits and malware that have yet to becategorized or identified within the security community, often meaningthere is no currently known defense to these attacks as the maintainersof the commercial or open source products being targeted are themselvesunaware of the flaw being exploited.

This module 220 is capable of dissecting the attack and recording thesmallest components, uncovering how every intricate step and securitymitigation tactic was used to achieve the attack. This module is basedon unique knowledge that the owner of BaitNET has developed throughvarious research projects.

The ZeroDAY module 220 is effective when presented with the most complexand customized/never before seen malware as used in advanced persistentthreat (APT) attacks. The module can be set to detect and catalog theattack, or detect and block the attack. Unlike EMET, Microsoft's currentsecurity mitigation technology, the ZeroDAY module utilizes the combinedfiltration of KERNEL32, KERNELBASE and NTDLL.

The ZeroDAY module may perform any or all of the following industryrecognized tasks for recognition and cataloging of exploits:

In-memory shellcode detection

Raw shellcode dumping (raw output of shell code to file)

Raw shellcode disassembly (post analysis)

Shellcode emulation

Identify APIs used in the shellcode

Log API parameter information:

-   -   Network    -   Memory    -   File    -   Process

ROP detection

ROP gadgets detection

ROP gadgets dumping with backward disassembly (module+function)

Heap spray detection

NOP sled detection

NULL page allocation detection

In general, the ZeroDAY module can monitor and protect any applicationin user-land (ring-three e.g., “r3”), but can only monitor and notprotect against kernel-land (ring-zero e.g., “r0”) exploits affectingthe operating system services directly. It will still, however, be ableto protect against kernel-based exploits being served through user-landand any other application that utilizes this attack vector.

The ZeroDAY module provides stack validation and monitoring thatincludes the protection from direct access to KERNEL32, KERNELBASE andNTDLL APIs. The module may also have a CODE/TEXT section permissionchange monitor. This monitor is a novel process/mechanism. Thismechanism allows the detection and monitoring of privilege escalationthrough a process whereby the system monitors for CODE/TEXT changes.This is possible due to the way that the ZeroDAY module integrates intothe kernel and ties directly into primary system sub processes.

A semi control-flow-transfer (CFT) check is part of the system and allsystem calls (r3) will still tunnel back to the original one in thekernel (r0). Therefore, calls will be filtered through KiFastSystemCall[SystemCallStub] (triggered by interrupt vector int 0x2E).

The ZeroDAY module was designed to not only to detect and stop theattack, but also to gather information post the attack. This informationmay include communication with a command and control (C&C) server andthe downloading of malware. It serves well to automate the detection,post-automated analysis of the attack and gathering in-depth informationfor data analysis (i.e. briefs and blog posts) that other individuals orcompanies do not have.

VM+SandBox Detection Avoidance and Circumvention Module

Almost all malware detects the presence of/if it is hosted by anoperating system managed as a virtual machine (VM.) aka “SandBox” andwill avoid execution and revealing their control-flow (CF) to bedynamically analyzed. This was developed to circumvent thisanti-detection capability in modern malware; it will detect whether thedropped malware is a result of an exploit or was simply the result oftypical drive-by's that attempt to avoid execution within a VM or aSandbox. There are multiple options for circumvention of theanti-detection technology within malware:

1) Direct in-memory patching based on signatures developed in the labusing advanced regular expressions and Boolean algebra

2) Hijacking the system calls made by the malware through a proxy stub,trampolining the original code with the new one and feeding the malwarethe wrong results tricking it to run as expected on a bare-metalmachine.

AI Module

This module is responsible in generating artificial human activity inthe VM. As some malware will check for the lack of mouse activity orkeyboard activity or even processes being spawned. The absence ofactivity from these human interface devices, along with the absence ofancillary processes and applications are indicative of a automatedmachine, and therefore a trap. The AT Module corrects this oversight inother incubation systems by injecting randomized mouse movements andusage, keyboard input to include realistic typing patterns, mistakesvariations in speed, etc. All of this produces a very realistic usage ofthe machine.

The AT module and Sandbox modules may be part of the system (like theZeroDay module) in FIGS. 1 and 2, but is not shown in these figures.

VM Templates

All the VM images being used across the stacks are created from custommade templates, which use the underpinning of the Control Process, whichintegrates the virtual machine controls into the base operating system,thus hiding the Guest OSes and appearing like a normal bare-metalmachine. This includes options such as:

Getting the PTR location

Setting the PTR location

Direct Exec

NT Reloc

Self Modification

Reloc

BT Segment

BT Privilege

BT Mem Space

BT IN Port

BT Out Port

The system and method for malware and exploit campaign detection is atechnical solution to a technical problem that did not exist prior tothe Internet and computer networks. Specifically, the technical problemis trying to detect malware and exploit campaigns on a computer andcomputer networks. This technical problem did not exist prior tocomputer networks and the Internet. The system and method for malwareand exploit campaign detection addresses this problem as disclosed usingthe capture stack that is configured to issue a uniform resource locatorto each computer system to download a piece of malicious code, thereplay stack that is configured to test the piece of malicious code in alive environment and generate data about the replay of the piece ofmalicious code, the proxy stack that is configured to perform testing ofthe piece of malicious code without accessing the uniform resourcelocator and the master hypervisor controller that controls the capturestack, the replay stack and the proxy stack. Furthermore, the system andmethod for malware and exploit campaign detection overcomes thelimitations of the conventional systems and methods as described above.

The system and method for malware and exploit campaign detection userules and the capture stack, the replay stack and the proxy stack (andtheir corresponding processes) to perform the malware and exploitcampaign detection. Furthermore, the system and method provide animproved technical result for malware and exploit campaign detectionusing the capture stack, the replay stack and the proxy stack (and theircorresponding processes) which are an advance and are an inventiveconcept over the conventional system as described above.

1. A malware and exploit campaign detection system, comprising: a plurality of computer systems; a capture stack, implemented on the computer system, that is configured to identify a plurality of malicious uniform resource locators that each have a piece of malicious code; a replay stack, implemented on the computer systems, that is configured to test each piece of malicious code from the capture stack in a live environment using a victim by accessing the malicious uniform resource locator and to generate data about the replay of each piece of malicious code, each victim having a configuration of an operating system, a browser and at least one application that is exploitable by an exploit; and wherein the capture stack has a scout process that gathers the plurality of malicious uniform resource locators and that sends each malicious uniform resource locator to a particular victim of the replay stack.
 2. The system of claim 1, wherein the scout process defines a first tier comprising a set of victims of the replay stack with each victim having a combination of an operating system, a browser and one or more applications that are targeted by an exploit, each first tier victim testing the uniform resource locators assigned to that first tier victim to identify a plurality of first level malicious uniform resource locators, wherein each first level malicious uniform resource locator exploits the combination of the operating system, the browser and the one or more applications on the first tier victims.
 3. The system of claim 2, wherein the scout process defines a second tier comprising a set of victims of the replay stack with each victim having a combination of an operating system, a browser and one application that are targeted by an exploit, each second tier victim testing a first level malicious uniform resource locator identified by the first tier to identify a plurality of second level malicious uniform resource locators from the first level malicious uniform resource locators, wherein each second level malicious uniform resource locator exploits the one application.
 4. The system of claim 3, wherein the scout process defines a third tier comprising a set of victims of the replay stack with each victim having a combination of the same operating system and browser as the second tier victim that identified the second level malicious uniform resource locator and a different version of the application of the second tier victim, each third tier victim testing a second level malicious uniform resource locator identified by the second tier to identify a plurality of third level malicious uniform resource locators from the second level malicious uniform resource locators wherein each third level malicious uniform resource locator exploits the different version of the application.
 5. The system of claim 1 further comprising a proxy stack that is configured to perform testing of the piece of malicious code without accessing the uniform resource locator and a master hypervisor controller that controls the capture stack, the replay stack and the proxy stack.
 6. The system of claim 5, wherein the capture stack, the replay stack and the proxy stack run in parallel.
 7. The system of claim 5 further comprising a zero day module that identifies zero day attacks.
 8. The system of claim 1, wherein the capture stack is configured to create a copy of the piece of malicious code and catalogs operating system changes caused by the piece of malicious code.
 9. The system of claim 1, wherein the capture stack is configured to capture communications with the plurality of computer systems.
 10. The system of claim 5, wherein each stack is one or more server computers.
 11. The system of claim 10, wherein each stack has a virtual machine.
 12. A method for malware and exploit campaign detection, comprising: identifying a plurality of malicious uniform resource locators wherein each malicious uniform resource locator contains a piece of malicious code; sending each of the plurality of malicious uniform resource locator to each of a plurality of victims, each victim having a configuration with an operating system, a browser and at least one application that are exploitable by an exploit of a malicious uniform resource locator; testing, at each victim, each of the plurality of malicious uniform resource locators in a live environment; and generating data about the replay of the malicious uniform resource locator and the piece of malicious code.
 13. The method of claim 12, wherein testing the plurality of uniform resource locators further comprises accessing each uniform resource locator using a first tier victim that has a combination of an operating system, a browser and one or more applications that are targeted by an exploit and identifying a plurality of first level malicious uniform resource locators, wherein each first level malicious uniform resource locator exploits the combination of the operating system, the browser and the one or more applications on the first tier victims.
 14. The method of claim 13, wherein testing the plurality of uniform resource locators further comprises accessing each uniform resource locator using a second tier victim that has a combination of an operating system, a browser and one application that are targeted by an exploit and identifying a plurality of second level malicious uniform resource locators from the first level malicious uniform resource locators, wherein each second level malicious uniform resource locator exploits the one application of the second tier victim.
 15. The method of claim 14, wherein testing the plurality of uniform resource locators further comprises accessing each uniform resource locator using a third tier victim that has a combination of the same operating system and browser as the second tier victims and a different version of the application of the second tier victim and identifying a plurality of third level malicious uniform resource locators from the second level malicious uniform resource locators wherein each third level malicious uniform resource locator exploits the different version of the application of the third tier victim.
 16. The method of claim 12 further comprising performing testing of the piece of malicious code without accessing the uniform resource locator.
 17. The method of claim 16 further comprising identifying a zero day attack.
 18. The method of claim 12 further comprising creating a copy of the piece of malicious code and cataloging operating system changes caused by the piece of malicious code.
 19. The method of claim 12 further comprising capturing communications with the plurality of computer systems. 